Today's more popular browsers, such as MICROSOFT'S INTERNET EXPLORER and MOZILLA FOUNDATION'S FIREFOX, use the HyperText Transport Protocol (HTTP) to exchange information over the Internet. HTTP is a request/response, synchronous, communication protocol, where one entity in a network (e.g., the browser) makes a connection to another network entity (e.g., a web server), sends a request to the other entity, and then waits for a reply from the other entity. Notably, the reply is sent only in response to the request. If a request is not made, a reply is not sent. Accordingly, information received in a reply can become stale.
Another mode of exchanging information over the Internet uses a publish/subscribe (pub/sub), asynchronous, communication protocol. Unlike HTTP, the pub/sub communications protocol allows an entity (subscriber) to subscribe to information provided by another entity (publisher). The publisher posts (or publishes) the information, e.g., data tuples, to a pub/sub service, which then selectively transmits the posted messages (through what are referred to as notify messages) to all interested parties, i.e., subscribers. The published information can be read simultaneously by any number of subscribers. Notably, in the pub/sub communications protocol, the pub/sub service transmits the information to the subscriber when the information is posted, and does not queue previously published data for retrieval when a subscriber is online such as with email and traditional topic-based message queues.
The pub/sub communication protocol is an example of an asynchronous communication protocol. The commands of an asynchronous protocol are structured such that there need not be a one-to-one correspondence between requests and responses exchanged between communication entities. In some cases a sender of information (e.g., a Publisher) via the protocol need not wait, nor expect a response from, a receiver (e.g., a Subscriber). Moreover, a receiver need not send a request for each response. That is, a receiver may receive multiple responses (e.g., Notifications) to a request (e.g., a Subscription) and/or may receive an unsolicited message (e.g., a Directed Notify). Thus, unlike HTTP where the reply is sent directly (synchronously) in response to the entity's request, the information can instead be sent in response to the publisher's posting of the information (i.e., asynchronous to the request of information). Accordingly, information received by the subscriber can be substantially up-to-date and timely.
Well known pub/sub communication protocols include presence protocols, which are used by presence services and Jabber Software Foundation's pub/sub protocol as specified in Jabber Enhancement Proposal (JEP) JEP0060: Publish-Subscribe. A presence protocol allows a presence client, e.g., a user, to subscribe to the presence information of another entity, e.g., a friend. The presence information of the friend can include the friend's status, e.g., “on-line,” “out-to-lunch,” and the friend's preferred communication mode. For example, a presence service typically conveys a user's presence on a network to other network users (subscribers) based on the user's connectivity to the network via a computing and/or communication device. The presence information describing a user's presence on the network can be used by applications and/or other services to provide what are referred to here as “presence applications”. Presence protocol data elements, known as tuples, must have a status element. General pub/sub protocols may support features equivalent to presence protocols, but pub/sub tuples, in general, have no content restrictions.
A popular presence application is instant messaging (IM). IM applications include Yahoo's YAHOO MESSENGER, Microsoft's MSN MESSENGER, and America Online's AOL INSTANT MESSENGER. IM applications use presence services to allow users to determine whether other users are present on (e.g., connected to) a network. Presence services can also be used to determine a user's status (e.g., available, not available, and the like) and a communication address for communicating with a user. The communication address can include both a means of communicating with the user (e.g., via a telephone or email) and a corresponding contact address (e.g., a telephone number or email address).
As the popularity of presence services has grown, the number of presence applications using different presence protocols has also increased. Some presence applications use proprietary architectures and protocols to implement their presence service components, while others use architectures and protocols based on standards. Among those are the architectures and protocols described in “Request for Comments” (or RFC) documents RFC 2778 to Day et al., titled “A Model for Presence and Instant Messaging” (February 2000), RFC 2779 to Day et al., titled “Instant Messaging/Presence Protocol” (February 2000), and RFC 3921 to Saint-Andre et. al, titled “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence”, each of which are incorporated here in their entirety by reference. Each different presence protocol exhibits varying levels of complexity and interoperability. As a result, a user typically cannot use a generic client, such as a web browser, to support different presence services. Instead, the user must install application-specific clients for each different presence service. This can be burdensome, particular for those devices that have limited resources. This situation exists for pub/sub protocols in general.